1.4.4 디버깅(Debugging)의 실종: 스택 트레이스(Stack Trace)가 없는 오류 추적의 어려움

1. 전통적 디버깅 메커니즘의 붕괴와 지적 통제의 상실

소프트웨어 엔지니어링의 역사에서 디버깅은 가설 검증의 연속적인 과정이었으며, 그 정점에 스택 트레이스(Stack Trace)가 존재했다. 프로그램이 예기치 않게 중단되거나 런타임 오류를 발생시킬 때, 시스템은 호출 스택의 역순을 정밀하게 기록하여 개발자에게 전달했다. 이는 오류가 발생한 정확한 소스 코드의 위치, 즉 파일명과 행 번호를 지목할 뿐만 아니라, 해당 지점에 도달하기까지의 함수 호출 경로를 명시적으로 드러내는 논리적 지도였다. 개발자는 이 지도를 바탕으로 결정론적 인과관계를 추적하고, 변수의 상태 변화를 중단점(Breakpoint)을 통해 확인하며 버그의 근본 원인을 제거할 수 있었다. 그러나 대규모 언어 모델(LLM)과 인공지능 에이전트가 소프트웨어의 핵심 로직을 담당하는 소프트웨어 2.0 시대로 진입하면서, 이 견고했던 디버깅의 기반은 근본적으로 흔들리고 있다.

AI 기반 소프트웨어에서 발생하는 대다수의 오류는 더 이상 Segmentation Fault나 NullPointerException과 같은 명시적인 하드웨어 또는 런타임 레벨의 비정상 종료로 나타나지 않는다. 대신 시스템은 겉보기에 멀쩡한 문장과 구조를 유지하면서도 내용 면에서 완전히 허구인 정보를 제공하거나, 비즈니스 로직에 위배되는 결정을 내리는 ’침묵하는 실패(Silent Failure)’를 양산한다. 모델이 할루시네이션(Hallucination)을 일으키거나 복잡한 추론 과정에서 논리적 비약을 범할 때, 전통적인 디버거는 어떠한 이상 신호도 감지하지 못한다. 프로그램의 실행 흐름 자체는 사전에 정의된 파이프라인을 정상적으로 통과하고 있기 때문이다. 이러한 가시성의 결여는 개발자로 하여금 시스템의 내부 동작을 블랙박스로 취급하게 만들며, 오류의 원인을 파악하기 위해 수천 줄의 텍스트 로그를 수동으로 분석해야 하는 원시적인 형태의 디버깅으로 퇴보하게 만든다.

스택 트레이스의 실종은 단순한 도구의 부재가 아니라, 소프트웨어 신뢰성을 담보하던 엔지니어링적 통제권의 상실을 의미한다. 과거에는 ’코드가 곧 로직’이었기에 코드를 읽는 것만으로도 문제 해결이 가능했으나, 이제는 ’가중치와 데이터가 로직’이 된 상황에서 수십억 개의 파라미터 사이에서 벌어지는 확률적 상호작용을 스택 트레이스로 표현하는 것은 불가능에 가깝다. 결국 개발자는 모델이 왜 그러한 결론에 도달했는지에 대한 인과적 증거를 찾지 못한 채, 프롬프트를 미세하게 조정하며 결과가 나아지기를 기도하는 비과학적인 접근 방식에 내몰리게 된다.

2. 비결정성의 기술적 근원: 부동 소수점 연산과 하드웨어의 무작위성

AI 모델의 디버깅이 어려운 근본적인 원인 중 하나는 재현의 불가능성을 초래하는 비결정성(Nondeterminism)에 있다. 전통적인 소프트웨어 버그 수정의 첫 단계는 오류를 일관되게 재현하는 것이지만, LLM은 동일한 질문에 대해서도 매번 다른 답변을 내놓을 수 있다. 이러한 현상은 단순히 모델 상단의 템퍼러처(Temperature) 설정 때문만이 아니라, 현대 컴퓨팅 인프라의 깊숙한 곳에서 발생하는 수치적 특성에서 기인한다.

가장 치명적인 원인은 부동 소수점 연산의 비결합성(Non-associativity)이다. 이론적인 수학과 달리 컴퓨터의 부동 소수점 연산에서는 연산 순서에 따라 결과가 미세하게 달라질 수 있다.
(a + b) + c \neq a + (b + c)
현대 GPU는 수만 개의 스레드가 병렬로 연산을 수행하며 결과를 누적한다. 이때 ’원자적 덧셈(Atomic Add)’과 같은 연산이 수행되는 순서는 각 스레드의 실행 속도나 스케줄링에 따라 비결정적으로 정해진다. 이 미세한 수치적 차이는 트랜스포머 아키텍처의 소프트맥스(Softmax) 층을 거치며 특정 토큰의 선택 확률을 미묘하게 변화시키고, 결국 완전히 다른 문장을 생성하는 방아쇠가 된다.

또한 추론 서버의 배치(Batching) 전략 역시 비결정성을 가중시킨다. vLLM과 같은 고성능 추론 엔진은 처리량을 극대화하기 위해 여러 사용자의 요청을 동적으로 묶어서 처리하는데, 이 과정에서 발생하는 KV 캐시의 레이아웃 변화나 연산 순서의 차이는 개별 요청의 결과값에 영향을 미친다. 개발자 입장에서는 로컬 환경에서 발생한 오류를 운영 환경에서 재현하려 해도, 당시 서버의 부하 상태나 함께 처리된 다른 요청들의 구성을 똑같이 모방할 수 없으므로 디버깅은 미궁에 빠지게 된다. 템퍼러처를 0으로 설정하더라도 이러한 하드웨어 및 시스템 레벨의 무작위성은 여전히 존재하며, 이는 결정론적 정답지를 기반으로 한 전통적인 QA 체계를 무력화한다.

3. 스택 트레이스를 대체하는 관측 가능성(Observability)의 등장

스택 트레이스가 사라진 공백을 메우기 위해 현대 AI 엔지니어링은 관측 가능성(Observability)이라는 개념을 도입했다. 이는 단순히 로그를 남기는 것을 넘어, 요청의 전 생애주기를 ’트레이스(Trace)’와 ’스팬(Span)’이라는 단위로 구조화하여 기록하는 방식이다. AI 트레이스는 모델의 입출력뿐만 아니라 프롬프트 템플릿의 버전, 검색된 지식 소스의 메타데이터, 사용된 모델 파라미터, 그리고 각 추론 단계에서 소요된 시간과 토큰 비용을 통합적으로 캡처한다.

관측 가능성 도구들은 모델의 ’사고 체인(Chain-of-Thought)’을 시각화하여 개발자가 로직의 비약이 발생한 지점을 특정할 수 있도록 돕는다. 예를 들어, 멀티 에이전트 시스템에서 특정 에이전트가 잘못된 도구(Tool)를 호출하여 오류가 발생했다면, 트레이스 뷰어는 해당 에이전트가 받은 지시사항과 이전 단계의 출력을 대조하여 왜 그런 판단을 내렸는지 추적할 수 있는 근거를 제공한다.

이러한 데이터는 기존의 스택 트레이스가 주지 못했던 ’문맥적 인과관계’를 설명해 주지만, 데이터의 규모가 방대하다는 새로운 난관을 야기한다. 하루에 수백만 건의 요청이 발생하는 서비스에서 모든 트레이스를 전수 조사하는 것은 불가능하므로, 결국 오류 패턴을 자동으로 감지하고 클러스터링하는 AI 기반의 분석 도구가 필연적으로 수반되어야 한다.

4. 침묵하는 실패의 탐지: 세밀한 분석과 추론 체인 추적의 난제

AI 기반 시스템에서 가장 다루기 힘든 버그는 시스템이 오류 없이 동작하지만 결과물이 질적으로 저하되는 ’침묵하는 실패’이다. 이는 전통적인 소프트웨어의 0으로 나누기와 같은 명백한 오류와 달리, 정답과 오답의 경계가 모호한 영역에서 발생한다. 에이전트가 복잡한 업무를 수행할 때, 50단계의 추론 과정 중 단 한 단계에서만 논리적 오류를 범하더라도 최종 결과는 완전히 오염될 수 있다. 이를 ’계단식 효과(Cascade Effect)’라고 하며, 스택 트레이스가 없는 상황에서 이 오염의 시작점을 찾는 것은 거대한 사막에서 바늘을 찾는 것과 같다.

이러한 문제를 해결하기 위해 제시되는 연구 중 하나는 Crash Report Enhancement with Large Language Models: An Empirical Study에서 다루는 것처럼, 기존의 불완전한 런타임 정보에 모델의 추론 능력을 결합하여 오류 보고서를 강화하는 방식이다. 연구에 따르면, 단순한 스택 트레이스만으로는 오류를 수정하기 어려운 경우에도 AI가 소스 코드의 맥락을 결합하여 분석하면 문제 해결 확률이 10.6%에서 43.1%까지 비약적으로 상승한다. 이는 스택 트레이스가 사라진 시대에 역설적으로 AI가 스스로의 오류를 진단하거나 전통적인 코드의 오류를 인간보다 더 깊게 파헤치는 도구가 될 수 있음을 시사한다.

하지만 추론 체인을 추적하는 데 있어서 ’모델의 자기 합리화’는 심각한 장애물이다. 모델은 자신이 내린 잘못된 결론을 정당화하기 위해 그럴듯한 거짓 논리를 생성할 수 있는데, 이는 개발자가 오류의 근원을 오판하게 만드는 함정으로 작용한다. 따라서 단순한 텍스트 기반의 추론 기록 외에도 모델 내부의 토큰 확률 분포나 어텐션 맵(Attention Map) 등을 활용한 보다 객관적인 디버깅 기법이 요구되지만, 상용 클로즈드 소스 모델(예: GPT-4, Gemini)을 사용할 경우 이러한 내부 정보에 접근할 수 없다는 한계가 명확하다.

5. 데이터 디버깅(Data Debugging): 코드 중심에서 지식 중심으로의 전환

소프트웨어 2.0 환경에서의 디버깅은 코드의 논리를 고치는 것보다 데이터를 정제하고 모델의 지식 소스를 관리하는 비중이 훨씬 크다. 많은 AI 실패 사례는 모델의 지능 부족이 아니라, 부적절한 데이터가 컨텍스트로 주입되었을 때 발생한다. 이를 위해 등장한 ‘데이터 디버깅’ 기법들은 오류의 원인을 모델 외부의 지식 베이스나 훈련 데이터셋에서 찾으려 노력한다.

Rain: Accelerating Data Science by Effective Debugging 연구에서 소개된 Rain 시스템은 SQL과 ML 추론이 결합된 환경에서 결과가 편향되거나 잘못되었을 때, 어떤 훈련 데이터가 그 원인이 되었는지를 역추적하는 기능을 제공한다. 이는 전통적인 프로그래밍의 watchpoint와 유사한 개념을 데이터 레벨로 확장한 것으로, 특정 데이터 속성이 모델의 의사결정에 미치는 영향을 정량화하여 디버깅의 단서를 제공한다. 또한 BigSift와 같은 시스템은 데이터 계보(Data Provenance)를 활용하여 오류를 유발한 최소 단위의 입력 레코드셋을 자동으로 격리한다.

이러한 데이터 중심 디버깅은 다음과 같은 세 가지 핵심 지표를 통해 정량화된다.

1. 컨텍스트 재현율(Context Recall): 답변에 필요한 핵심 정보가 지식 베이스에서 제대로 추출되었는가?
2. 컨텍스트 정밀도(Context Precision): 추출된 정보들 중 답변과 무관한 ’소음(Noise)’이 얼마나 섞여 있는가?
3. 근거성(Faithfulness): 모델의 최종 답변이 오직 제공된 컨텍스트에만 기반하고 있는가, 아니면 모델의 자체적인 할루시네이션이 포함되었는가?

이 지표들은 스택 트레이스가 주지 못하는 ’데이터 기반의 진단 결과’를 제공하며, 개발자가 검색 알고리즘을 개선해야 할지 아니면 모델의 프롬프트를 수정해야 할지를 결정하는 나침반 역할을 한다.

6. 블랙박스 모델에 대한 엔지니어링적 통제: 오라클과 샌드박스

추적할 수 없는 오류에 대응하는 가장 강력한 전략은 ’확정적인 경계’를 설정하는 것이다. 비결정적인 모델의 출력을 검증하기 위해 결정론적 정답지를 제공하는 오라클(Oracle)을 시스템 곳곳에 배치해야 한다. 오라클은 모델의 응답이 사전에 정의된 규칙이나 스키마, 또는 외부 API의 실행 결과와 일치하는지를 판별하는 심판자 역할을 수행한다.

예를 들어, 코드 생성 AI를 디버깅할 때 단순히 생성된 코드가 ’보기 좋은지’를 따지는 것이 아니라, 격리된 샌드박스 환경에서 실제로 컴파일하고 단위 테스트를 실행하는 오라클을 구축할 수 있다. 이때 발생하는 컴파일 에러 메시지는 전통적인 스택 트레이스와 결합하여 모델에게 피드백으로 전달되며, 이를 통해 모델은 스스로 오류를 수정(Self-repair)할 수 있는 기회를 얻는다. 이는 AugmenTest 연구에서 보여주듯, 모델이 작성한 코드의 의도를 문서와 대조하여 올바른 테스트 오라클을 자동 생성함으로써 인간 개발자의 개입 없이도 디버깅 루프를 완성하는 수준에 이르고 있다.

이러한 오라클 시스템은 스택 트레이스가 제공하던 ’실행 시점의 안전장치’를 시스템 아키텍처 수준으로 격상시킨 것이다. 개발자는 모델의 내부를 완벽히 이해하지 못하더라도, 오라클이 설정한 경계 조건을 통해 시스템의 신뢰성을 통계적으로 보장받을 수 있다.

7. ’느낌적 코딩(Vibe Coding)’의 종말과 엄격한 로그 분석 체계

디버깅 수단의 부재는 개발자들 사이에 프롬프트를 조금씩 바꿔보며 감각적으로 문제를 해결하려는 이른바 ’느낌적 코딩(Vibe Coding)’을 확산시켰다. 하지만 이는 엔지니어링 측면에서 매우 위험한 도박이다. 특정 입력에 대해 결과가 좋아졌다고 해서 전체 시스템의 성능이 개선되었다고 단정할 수 없으며, 오히려 다른 케이스에서의 대규모 리그레션(Regression)을 유발할 수 있기 때문이다.

엄격한 엔지니어링 문화를 유지하기 위해서는 모든 오류 사례를 ’골든 데이터셋(Golden Dataset)’으로 자산화해야 한다. 운영 환경에서 발견된 실패한 트레이스는 즉시 테스트 케이스로 변환되어야 하며, 프롬프트나 모델 파라미터를 수정할 때마다 전체 데이터셋에 대한 벤치마킹을 수행해야 한다. 스택 트레이스가 알려주던 “이 라인이 틀렸다“는 단편적인 정보 대신, “이 수정으로 인해 전체 정확도가 5% 하락했다“는 통계적 증거를 바탕으로 의사결정을 내려야 한다.

또한, ’플라이트 레코더(Flight Recorder)’와 같이 에이전트의 모든 활동을 실시간으로 데이터베이스에 기록하고 사후에 리플레이(Replay)할 수 있는 인프라가 필수적이다. 이는 오류가 발생한 시점의 환경 변수, 모델 상태, 데이터 유입 경로를 완벽하게 보존하여, 비결정성의 파도 속에서도 최소한의 재현 가능성을 확보하려는 눈물겨운 엔지니어링적 노력이다.

8. 자가 치유 시스템으로의 진화: 디버깅 주체의 전환

미래의 디버깅은 인간이 스택 트레이스를 읽고 분석하는 형태에서 탈피하여, 시스템이 스스로 오류를 감지하고 수정하는 ‘자가 치유(Self-healing)’ 모델로 진화할 것이다. DEVLoRe 프롬프트 프레임워크와 같은 최신 연구들은 모델에게 이슈 설명, 스택 트레이스, 디버그 정보를 동시에 입력으로 제공하여 인간 개발자처럼 오류의 위치를 특정하고 패치를 생성하도록 유도한다. 분석 결과, 이슈 내용과 스택 트레이스를 결합했을 때 단일 메소드 버그의 위치를 찾는 정확도가 49.3%까지 도달하며, 이는 인간 엔지니어의 생산성을 극대화할 수 있는 수치이다.

또한 대규모 추론 모델(LRM)의 등장은 디버깅의 양상을 다시 한번 변화시키고 있다. 단순한 패턴 매칭을 넘어 내부적으로 가설을 세우고 검증하는 ’사고의 시간(Time-to-think)’을 갖는 모델들은 복잡한 분산 시스템의 로그와 트레이스를 분석하여 인간이 놓치기 쉬운 미세한 인과관계의 사슬을 찾아낸다. 이제 디버깅은 “어디가 고장 났는가?“를 찾는 행위에서 “시스템이 의도한 패턴을 왜 벗어났는가?“를 AI와 함께 탐구하는 과정으로 변모하고 있다.

9. 결론: 암흑 속에서 신뢰를 구축하는 법

스택 트레이스의 실종은 소프트웨어 엔지니어링이 마주한 거대한 도전이자, 새로운 시대로 나아가기 위한 통과의례이다. 선형적이고 결정론적인 세계관에서 벗어나 확률과 통계, 그리고 지속적인 관측에 기반한 디버깅 패러다임을 수용해야 한다. 우리는 더 이상 한 줄의 에러 메시지에 의존할 수 없지만, 대신 수백만 개의 트레이스 데이터와 정교한 오라클 시스템을 통해 과거보다 더 넓은 시야에서 시스템의 건강 상태를 진단할 수 있게 되었다.

결국 AI 시대의 우수한 엔지니어는 스택 트레이스를 잘 읽는 사람이 아니라, 시스템이 스스로를 설명할 수 있도록 관측 가능성을 설계하고, 비결정적인 모델의 출력 사이에서 결정론적인 정답의 경계를 명확히 긋는 오라클 아키텍처를 구축하는 사람이다. 이러한 노력이 뒷받침될 때에만, 우리는 AI라는 블랙박스를 길들이고 신뢰할 수 있는 미래의 소프트웨어를 완성할 수 있을 것이다.

10. 참고 자료

1. Debugging Agents is Tough: How I Built a “Flight Recorder” for AI Kernel - DEV Community, https://dev.to/mosiddi/debugging-agents-is-tough-how-i-built-a-flight-recorder-for-ai-kernel-44m0
2. What If Your Monitoring Tool Could Actually Fix the Bug? - OneUptime, https://oneuptime.com/blog/post/2026-02-13-ai-agents-that-fix-your-production-bugs/view
3. How to Debug LLM Failures: A Complete Guide for Reliable AI …, https://dev.to/kuldeep_paul/how-to-debug-llm-failures-a-complete-guide-for-reliable-ai-applications-3g5h
4. feststelltaste/awesome-agentic-software-modernization: A curated list of tools, frameworks, patterns, and research for AI-driven and agentic approaches to modernizing legacy systems - GitHub, https://github.com/feststelltaste/awesome-agentic-software-modernization
5. How to Effectively Debug LLM Failures: A Step-by-Step Guide - DEV Community, https://dev.to/kuldeep_paul/how-to-effectively-debug-llm-failures-a-step-by-step-guide-2e8n
6. Why AI Can’t Replace Debugging Skills (And What You Can Do …, https://dev.to/jaideepparashar/why-ai-cant-replace-debugging-skills-and-what-you-can-do-instead-2762
7. How to Debug LLM Failures: A Practical Guide for AI Engineers - DEV Community, https://dev.to/kuldeep_paul/how-to-debug-llm-failures-a-practical-guide-for-ai-engineers-n27
8. What Is LLM Observability? A Comprehensive Guide - Elastic, https://www.elastic.co/what-is/llm-observability
9. A guide to LLM debugging, tracing, and monitoring | genai-research – Weights & Biases, https://wandb.ai/onlineinference/genai-research/reports/A-guide-to-LLM-debugging-tracing-and-monitoring–VmlldzoxMzk1MjAyOQ
10. Non-Deterministic Behaviour - FINOS AI Governance Framework:, https://air-governance-framework.finos.org/risks/ri-6_non-deterministic-behaviour.html
11. Defeating Non-Determinism in LLMs: Solving AI’s Reproducibility Crisis | FlowHunt, https://www.flowhunt.io/blog/defeating-non-determinism-in-llms/
12. Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
13. The Modern AI Observability Stack: Understanding AI Agent Tracing - Maxim AI, https://www.getmaxim.ai/articles/the-modern-ai-observability-stack-understanding-ai-agent-tracing/
14. LLM Observability: Tutorial & Best Practices - Patronus AI, https://www.patronus.ai/llm-testing/llm-observability
15. Top 7 LLM Observability Tools in 2026 - Confident AI, https://www.confident-ai.com/knowledge-base/top-7-llm-observability-tools
16. AI-first debugging: Tools and techniques for faster root cause analysis - LogRocket Blog, https://blog.logrocket.com/ai-debugging/
17. Why Traditional Testing Fails for AI Agents (and What Actually Works) - Coralogix, https://coralogix.com/ai-blog/why-traditional-testing-fails-for-ai-agents-and-what-actually-works/
18. Crash Report Enhancement with Large Language Models: An Empirical Study, https://www.researchgate.net/publication/395583066_Crash_Report_Enhancement_with_Large_Language_Models_An_Empirical_Study
19. DataPrism: Exposing Disconnect between Data and Systems - ORBilu, https://orbilu.uni.lu/bitstream/10993/57629/1/3514221.3517864.pdf
20. Accelerating Data Science: Systems for Effective Debugging and Efficient Data Loading - SFU Summit, https://summit.sfu.ca/_flysystem/fedora/2025-07/etd23865.pdf
21. How to do a million watchpoints: Efficient Debugging using Dynamic Instrumentation - DSpace@MIT, http://dspace.mit.edu/bitstream/handle/1721.1/35778/CS005.pdf;sequence=1
22. Automated Debugging in Data-Intensive Scalable Computing - PMC - PubMed Central, https://pmc.ncbi.nlm.nih.gov/articles/PMC6473804/
23. LLM Observability: The Ultimate Guide for AI Developers - Comet, https://www.comet.com/site/blog/llm-observability/
24. Do LLMs Generate Useful Test Oracles? An Empirical Study with an Unbiased Dataset | Request PDF - ResearchGate, https://www.researchgate.net/publication/400203139_Do_LLMs_Generate_Useful_Test_Oracles_An_Empirical_Study_with_an_Unbiased_Dataset
25. TOGLL: Correct and Strong Test Oracle Generation … - IEEE Xplore, https://ieeexplore.ieee.org/iel8/11029684/11029718/11029748.pdf
26. Integrating Various Software Artifacts for Better LLM-based Bug Localization and Program Repair - arXiv.org, https://arxiv.org/html/2412.03905v3
27. AugmenTest: Enhancing Tests with LLM-Driven Oracles - arXiv, https://arxiv.org/html/2501.17461v1
28. Understanding LLM-Driven Test Oracle Generation - arXiv, https://arxiv.org/html/2601.05542v1
29. Large Reasoning Models: The Complete Guide to Thinking AI (2025) | by Nayeem Islam, https://medium.com/@nomannayeem/large-reasoning-models-the-complete-guide-to-thinking-ai-2025-b07d252a1cca